1. Technical Field
The teachings presented herein relate to methods and systems for a domain name translation service with dynamic traffic control.
2. Discussion of Related Art
There are various conventional domain name system (DNS) implementations. In those implementations, a DNS server resolves a DNS query by returning one or more IP addresses corresponding to a domain name whether or not the underlying application server associated with the domain name is actually available. This is shown in FIG. 1(a). There are a plurality of application servers 2, . . . , 4. Each application server offers the same service represented by an URL (Uniform Resource Locator) link or a domain name. Although an URL usually includes two parts: domain name and communication protocol, for simplicity, the term “URL” refers to either the domain name or the entire URL in this document to cover different implementation options, with the understanding that a DNS server translates domain name into IP address(es). Each application server also has an associated IP address. For example, the application server 1 may offer service represented by a link URL1 and may have an underlying IP address IP Addr1. In operation, a user 10, which may be a user's application program installed in a human-user facing terminal or device, inputs an URL representing a service provided by an application server to a DNS client 8. The DNS client 8 formulates a DNS query based on the provided URL and sends the DNS query to a DNS server 6. The DNS server 6 then resolves the DNS query by returning an IP address of an application server that provides the application/service represented by the URL to the DNS client 8. The returned IP address is obtained based on the translation information, commonly known as zone data, stored in the DNS server 6. Upon receiving the returned IP address, the DNS client 8 provides the IP address to the user 10; and the user 10 connects to an application server by using the returned IP address to request the desired service or application.
During such operation, the DNS server 6 does not monitor the condition of any of the application servers 2 . . . 4. If an application server, say application server 1, malfunctions or is unavailable, since the DNS server 6 is not aware that application server 1 is not accessible, it still returns the IP address of the application server 1 to the DNS client 8. As a result, when the user 10 contacts the application server 1 for the desired service, the user 10 may not be able to receive service in a timely manner.
FIGS. 1(b)-1(d) show some commonly deployed DNS schemes designed to address such problems. In FIG. 1(b), two different URLs, say URL1 and URL2, may be designated separately for the primary server and back-up server for the same service. In other words, application server 14 represents the primary server and application server 16 represents the backup server, and both servers are deployed together as application server 12 to provide a particular service. Each application server has its own distinct IP address, say IP Addr1 and IP Addr2, respectively. In operation, when a user 10 inputs a request for URL1 for the primary server and URL2 for the backup server to a DNS client 20, the DNS client 20 obtains IP Addr1 and IP Addr2 for URL1 and URL2, respectively, from a DNS server 18 for the user 10. The user 10 may request the desired service from the primary server first by using IP Addr1. If it fails to receive desired service from the primary server, the user 10 may then request the service from the backup server by using IP Addr2. With this scheme, the backup server 16 may remain idle as long as server 14 is available. A DNS client 20 may request IP addresses for both domain names in a single DNS query or it may send two separate DNS queries, one for each domain name. In either scenario, such a scheme may be time consuming.
FIG. 1(c) shows a different DNS scheme, in which a plurality of application servers 22-1, 22-2, . . . p 22-3 with different IP addresses (IP Addr1, IP Addr2, . . . , IP Addrk) support a particular service associated with an URL. When a user 30 inputs the URL to a DNS client 28, the DNS client 28 formulates a DNS query based on the URL and sends it to a DNS server 24. The translation data, known as zone data, for that domain name is stored in a data file, known as a zone file, in the DNS server 24. A zone file contains a plurality of resource record (RR) entries 26, each containing the corresponding IP addresses for one of the application servers 22-1, 22-2, . . . , 22-3. This type of resource record is commonly known as the A (Address) record. The DNS server 24 then returns, to the DNS client 28, a list containing all IP addresses, IP Addr1, IP Addr2, . . . , IP Addrk, in response to the DNS query. DNS sever 24 may reorder the IP addresses in the list in a round robin manner so that the first IP address is different for each DNS query to ensure equal chance for each application server to offer service to users. Upon receiving the list of IP addresses, the DNS client 28 provides the list of addresses to the user 30. The user 30 may request a desired service by using the IP addresses in the list, one at a time, according to the order in the list, until it successfully receives the service. For example, if the user 30 first uses IP Addr2 to access application server 2 and fails to receive service, the user 30 may then use the next IP address in the list to access a different application server. This process continues until the desired service can be obtained.
FIG. 1(d) illustrates another DNS scheme 100 with load balancer balancers. A DNS server 115 is responsible to resolve DNS queries corresponding to a plurality of applications/services 130, . . . 140, with help from other domain name servers (or load balancer balancers in this example). Each URL may correspond to multiple application servers that provide the same service. For example, application servers 130-1, . . . , 130-2 correspond to first service 130, and application servers 140-1, . . . , 140-2 correspond to the kth service 140. For each service, there is a load balancer 120. For example, service 130 has a load balancer 120-1, and service 140 has a load balancer 120-k. Each load balancer is responsible for balancing the traffic to its associated application servers, and it may monitor each application server and direct traffic based on their load or health conditions.
In operation, a user 105 inputs an URL to a DNS client 110, which subsequently sends a corresponding DNS query to a DNS server 115. Depending on the requested domain name, the DNS server 115 re-directs the DNS query to a load balancer 120 associated with service 130 or service 140, according to the resource records (RR) stored on the DNS server 115. This type of resource record is commonly known as the NS (name server) record. The load balancer 120 then determines which application server should receive the traffic and returns the appropriate IP address to the DNS server 115. In this scheme, the DNS server re-directs the DNS query to another server for domain name resolution and then passes the returned result from the other server to the DNS client. Although a load balancer can usually avoid directing traffic to an unavailable or malfunctioning application server, this scheme requires an additional layer of DNS query. As a result, it introduces increased delay in DNS query processing with an additional point of failure to the network.
Hence, a need still exists for a DNS query scheme that can efficiently direct traffic to appropriate application servers.